home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9459 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.9 KB
  1. Path: hunter.premier.net!insync!usenet
  2. From: bretting@insync.net (Greg Bretting)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: Wed, 27 Mar 1996 23:04:01 -0800
  6. Organization: - not one of my strong points, really...
  7. Message-ID: <4jd6e0$kbo@drencrom.insync.net>
  8. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net> <4j468j$gg1@drencrom.insync.net> <4j68or$nug@navajo.gate.net> <4j7iai$qcc@drencrom.insync.net> <4jbasq$102o@navajo.gate.net>
  9. NNTP-Posting-Host: line-223.insync.net
  10. X-Newsreader: Forte Agent .99b.112
  11.  
  12. On 27 Mar 1996 07:04:42 -0500, dhaire@gate.net (doug haire) wrote:
  13.  
  14. [snip]
  15. >: What does _that_ have to do with anything?  You said above that you were
  16. >: using a null modem cable, and if that's the case then my LapLink example is
  17. >: perfectly valid because it's essentially the same setup except for
  18. >: different application software being used.
  19. >
  20. >Bingo! The same thing EXCEPT for the software involved. You are using 
  21. >software designed to dedicate all of the CPU to the task. That's why I 
  22. >said apples and oranges.
  23.  
  24. Well, let's see - LapLink is designed to transfer data to and from a serial
  25. connection, perform error checking, and doing disk I/O.  How does this
  26. substantially differ from the comm software you were using?
  27.  
  28. >If you don't understand the difference between using LapLink and running 
  29. >a comm program protocol on a null modem cable at full speed then you 
  30. >aren't grasping the concept.
  31.  
  32. See above...
  33.  
  34. >: >: >When the common computer software platform is capable of handling 115200 
  35. >: >: >properly perhaps we can then consider the 230k UART speed.
  36. >: >: 
  37. >: >: Well, DOS 6.2 is pretty common, and I know that I've been able to (almost)
  38. >: >: saturate the port at 115200 without any errors.  Here's a log from one such
  39. >: >: test using QModem Pro for DOS, a Courier V.34 external, and plain 16550
  40. >: >: UART:
  41. >: >: 
  42. >: >: 22:40:52  09-14-95  Online Timer Started
  43. >: >: 22:42:00  09-14-95  Download File(s).  Protocol : Zmodem
  44. >: >: 22:42:01  09-14-95  ++ File 1MEGTEST.RUN
  45. >: >: 22:43:34  09-14-95  ++ End of file
  46. >: >: 22:43:34  09-14-95  ++ Chars Per Second    : 11272
  47. >: >: 22:43:34  09-14-95  ++ Effective Percent   : 0%
  48. >: >: 22:43:40  09-14-95  Elapsed Online 00:02:48
  49. >: >
  50. >: >Sure and I have also. In fact, I posted several articles showing this on 
  51. >: >transfers between computers over phone lines and modems. That's not, of 
  52. >: >course, what I was talking about here and it has little to do with my point.
  53.  
  54. But the above _does_ illustrate a case where a common DOS platform
  55. functions well at a 115200bps DTE rate, which is a possibility you seemd to
  56. take issue with in your "When the common computer software platform is
  57. capable of handling 115200 properly perhaps we can then consider the 230k
  58. UART speed." comment.
  59.  
  60. >: Then I obviously am missing your point; I interpreted it to be that you
  61. >: felt 115200 DTE rates were unworkable on DOS platforms, let alone 230,400,
  62. >: and that discussion of DTE rates > 115200 were pointless since 115200
  63. >: didn't work very well on most platforms.  I then provide two examples, one
  64. >: using a null modem connection and another a dial-up session with an
  65. >: external modem, that seem to contradict what you are saying.  
  66. >
  67. >No, I offered that 115200 DTE rates were more than adequate for current 
  68. >operating system platforms in the real world. That having a port set to 
  69. >230k (and a modem that would accept that) is unnecessary and simply 
  70. >advertising hype.
  71. >
  72. >You offered a link using a specialized piece of software as a counter to 
  73. >this. Different game.
  74.  
  75. To begin with, I wasn't arguing that 230.4Kbps DTE rates made sense - I was
  76. addressing your apparent (to me, anyway) claim that DOS-based platforms
  77. weren't up to the task of supporting 115.2Kbps port speeds.  Let's also not
  78. forget the example I offered involving a fairly common DOS based comm app
  79. (Qmodem Pro, in case you forgot).
  80.  
  81. >: Not only that, but I know for a fact that I can connect two modems to _one_
  82. >: DOS machine and pass data full-duplex (simultaneous send and receive of the
  83. >: same file) between the ports at 115200 without errors.  This is normally
  84. >: how I run throughput testing on modems, using SoftArt's HowFast v1.65
  85. >: testing software running under DOS, on a wide variety of machines.  
  86. >
  87. >How do you connect two modems and pass data at 115200 between them? 
  88. >Answer: you don't. You pass data from a port to a modem on one end and 
  89. >from a modem to a port on the other at that speed; between the modems, 
  90. >you are limited to the DCE rate of the modems.
  91.  
  92. What, did we forget entirely about the subject of this thread - namely,
  93. compression?  The DCE-DCE rate isn't the important part, it's the rate at
  94. which the modem presents data _after compression_ to the DTE - which,
  95. depending on the file, can be substantially higher than the DCE rate and
  96. can under certain circumstances approach the limit of the port speed.
  97. Regardless of whether we are talking about a NMC or modem call with data
  98. compression enabled, the examples that have been discussed involve data
  99. rates being presented to the DTE at or near it's limit (as configured) of
  100. 115.2Kbps.  Unless I'm missing something (always a possibility I'm willing
  101. to accept), there isn't much difference between a NMC connection that
  102. presents data to the DTE at 115200 and a modem with data compression
  103. enabled operating at a sufficient speed and passing highly compressible
  104. data to the DTE at speeds very closely approaching the limit of the port.
  105.  
  106. Not only that, but keep in mind that in the above example, only _one_ CPU
  107. and DOS environment is servicing the interrupt load for _both_ ports.
  108.  
  109. >: Doug, I didn't just start doing this stuff yesterday - I know for a fact
  110. >: that MS-DOS is perfectly capable of supporting 115200 DTE rates, and I've
  111. >: demonstrated that on dozens of machines and literally hundreds of modems
  112. >: during the course of testing these things, using all sorts of software, and
  113. >: I know that it works.  
  114. >
  115. >Good, then you can simply ignore what I said and hit Enter. Or you can 
  116. >discuss this without bringing in specialized software designed to 
  117. >overcome DOS's limitations.
  118.  
  119. Well, okay then, let's deal with the examples I've posed so far that aren't
  120. "specialized" software - namely, the QModem Pro log I posted previously and
  121. the Procomm Plus/Win 2.11 screenshot I uploaded to alt.binaries.misc (which
  122. I posted yesterday, have you seen it?)- both of which demonstrate
  123. throughput on a DOS platform in excess of 11,000 cps.  Whatever the
  124. limitations of DOS may be (and I'm not saying there aren't any), it doesn't
  125. take exotic programming to overcome them - it would appear to me that just
  126. about any competently written and properly configured comm app will do just
  127. fine.
  128.  
  129.  
  130.  
  131. -- 
  132. |     Greg Bretting     |"The whole problem with the world is that  |
  133. |  bretting@insync.net  |fools and fanatics are always so certain of|
  134. |     --==<< >>==--     |themselves, but wiser people are so full of|
  135. |            |doubts." - Bertrand Russell            |
  136.  
  137.